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Abstract 

This paper reports on two approaches to provide a 
general-purpose audio programming support for web 
applications based on Csound. It reviews the cur¬ 
rent state of web audio development, and discusses 
some previous attempts at this. We then introduce 
a Javascript version of Csound that has been crea¬ 
ted using the Emscripten compiler, and discuss its 
features and limitations. In complement to this, we 
look at a Native Client implementation of Csound, 
which is a fully-functional version of Csound running 
in Chrome and Chromium browsers. 
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1 Introduction 

The web browser has become an increasingly 
viable platform for the creation and distributi¬ 
on of various types of media computing appli- 
cations[Wyse and Subramanian, 2013]. It is no 
surprise that audio is an important part of these 
developments. For a good while now we have be¬ 
en interested in the possibilities of deployment 
of client-side Csound-based applications, in ad¬ 
dition to the already existing server-side capa¬ 
bilities of the system. Such scenarios would be 
ideal for various uses of Csound. For instance, 
in Education, we could see the easy deployment 
of Computer Music training software for all le¬ 
vels, from secondary schools to third-level in¬ 
stitutions. For the researcher, web applications 
can provide an easy means of creating proto¬ 
types and demonstrations. Composers and me¬ 
dia artists can also benefit from the wide reach 
of the internet to create portable works of art. 
In summary, given the right conditions, Csound 
can provide a solid and robust general-purpose 
audio development environment for a variety of 
uses. In this paper, we report on the progress 
towards supporting these conditions. 


2 Audio Technologies for the Web 

The current state of audio systems for world¬ 
wide web applications is primarily based upon 
three technologies: Java 1 , Adobe Flash 2 , and 
HTML5 Web Audio 3 . Of the three, Java is the 
oldest. Applications using Java are deployed via 
the web either as Applets 4 or via Java Web 
Start 5 . Java as a platform for web applications 
has lost popularity since its introduction, pri¬ 
marily due to historically sluggish start-up ti¬ 
mes as well as concerns over security breaches. 
Also of concern is that major browser vendors 
have either completely disabled Applet loading 
or disabled them by default, and that NPAPI 
plugin support, with which the Java plugin for 
browsers is implemented, is planned to be drop¬ 
ped in future browser versions 6 * . While Java sees 
strong support on the server-side and desktop, 
its future as a web-deployed application is te¬ 
nuous at best and difficult to recommend for 
future audio system development. 

Adobe Flash as a platform has seen large- 
scale support across platforms and across brow¬ 
sers. Numerous large-scale applications have be¬ 
en developed such as AudioTool', Patchwork 8 , 
and Noteflight 9 . Flash developers can choose to 
deploy to the web using the Flash plugin, as 
well as use Adobe Air 10 to deploy to desktop 
and mobile devices. While these applications de¬ 
monstrate what can be developed for the web 
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using Flash, the Flash platform itself has a 
number of drawbacks. The primary tools for 
Flash development are closed-source, commer¬ 
cial applications that are unavailable on Linux, 
though open source Flash compilers and IDEs 
do exist 11 . There has been a backlash against 
Flash in browsers, most famously by Steve Jobs 
and Apple 12 , and the technology stack as a who¬ 
le has seen limited development with the gro¬ 
wing popularity of HTML5. At this time, Flash 
may be a viable platform for building audio ap¬ 
plications, but the uncertain future makes it dif¬ 
ficult to recommend. 

Finally, HTML5 Web Audio is the most re¬ 
cent of technologies for web audio applications. 
Examples include the “Recreating the sounds of 
the BBC Radiophonic Workshop using the Web 
Audio API” site 13 , Gibberish 14 , and WebPd 15 . 
Unlike Java or Flash, which are implemented 
as browser plug-ins, the Web Audio API is a 
W3C proposed standard that is implemented by 
the browser itself. 16 Having built-in support for 
Audio removes the security issues and concerns 
over the future of plug-ins that affect Java and 
Flash. However, the Web Audio API has limita¬ 
tions that will be explored further below in the 
section on Emscripten. 

3 Csound-based Web Application 
Design 

Csound is a music synthesis system that has 
roots in the very earliest history of computer 
music. Csound use in Desktop and Mobile app¬ 
lications has been discussed previously in [Laz- 
zarini et ah, 2012b], [Yi and Lazzarini, 2012], 
and [Lazzarini et ah, 2012a]. 

Prior to the technologies presented this pa¬ 
per, Csound-based web applications have em¬ 
ployed Csound mostly on the server-side. For 
example, NetCsound 17 allows sending a CSD 
file to the server, where it would render the 
project to disk and email the user a link to 
the rendered file when complete. Another use of 

n http: //www. flashdevelop. org/ 
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Csound on the server is Oeyvind Brandtsegg’s 
VLBI Music 18 , where Csound is running on the 
server and publishes its audio output to an au¬ 
dio stream that end users can listen to. A simi¬ 
lar architecture is found in [Johannes and To- 
shihiro, 2013]. Since version 6.02, Csound also 
includes a built-in server, that can be activa¬ 
ted through an option on start up. The server 
is able to receive code directly through UDP 
connections and compile them on the fly. 

Using Csound server-side has both positives 
and negatives that should be evaluated for a 
project’s requirements. It can be appropriate to 
use if the project’s design calls for a single audio 
stream/Csound instance that is shared by all 
listeners. In this case, users might interact with 
the audio system over the web, at the expen¬ 
se of network latency. Using multiple realtime 
Csound instances, as would be the case if there 
was one per user, would certainly be taxing for 
a single server and would require careful resour¬ 
ce limiting. For multiple non-realtime Csound 
instances, as in the case of NetCsound, multi¬ 
ple jobs may be scheduled and batch processed 
with less problems than with realtime systems, 
though resource management is still a concern. 

An early project to employ client-side audio 
computation by Csound was described in [Casey 
and Smaragdis, 1996], where a sound and music 
description system was proposed for the rende¬ 
ring of network-supplied data streams. A possi¬ 
bly more flexible way to use Csound in client- 
side applications, however, is to use the web 
browser as a platform. Two attempts at this ha¬ 
ve been made in the past. The first was the now- 
defunct ActiveX Csound (also known as AXC- 
sound) 19 , which allowed embedding Csound into 
a webpage as an ActiveX Object. This technolo¬ 
gy is no longer maintained and was only availa¬ 
ble for use on Windows with Internet Explo¬ 
rer. A second attempt was made in the Mobile 
Csound Project [Lazzarini et ah, 2012b], where a 
proof-of-concept Csound-based application was 
developed with Java and deployed using Java 
Web Start, achieving client-side Csound use via 
the browser. However, the technology required 
special permissions to run on the client side and 
required Java to be installed. Due to those issu¬ 
es and the unsure future of Java over the web, 
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the solution was not further explored. 

The two systems described in this paper are 
browser-based solutions that run on the client- 
side. The both share the following benefits: 

• Csound has a large array of signal proces¬ 
sing opcodes made immediately available 
to web-based projects. 

• They are compiled using the same source 
code as is used for the desktop and mo¬ 
bile version of Csound. They only require 
recompiling to keep them in sync with the 
latest Csound features and bug fixes. 

• Csound code that can be run with the¬ 
se browser solutions can be used on other 
platforms. Audio systems developed using 
Csound code is then cross-platform across 
the web, desktop, mobile, and embed¬ 
ded systems (i.e. Raspberry Pi, Beaglebo- 
ne; discussed in [Batchelor and Wignall, 
2013]). Developers can reuse their audio co¬ 
de from their web-based projects elsewhere, 
and vice versa. 

4 Emscripten 

Emscripten is a a project created by Alon Za- 
kai at the Mozilla Foundation that compiles the 
assembly language used by the LLVM compi¬ 
ler into Javascript [Zakai, 2011]. When used in 
combination with LLVM’s Clang frontend, Em¬ 
scripten allows applications written in C/C-l—h 
or languages that use C/C++ runtimes to be 
run directly in web browsers. This eliminates 
the need for browser plugins and takes full ad¬ 
vantage of web standards that are already in 
common use. 

In order to generate Javascript from C/C++ 
sourcecode the codebase is first compiled into 
LLVM assembly language using LLVM’s Clang 
frontend. Emscripten translates the resulting 
LLVM assembly language into Javascript, speci¬ 
fically an optimised subset of Javascript entitled 
asm.js. The asrn.js subset of Javascript is inten¬ 
ded as a low-level target language for compilers 
and allows a number of optimisations which are 
not possible with standard Javascript 20 . Code 
semantics which differ between Javascript and 
LLVM assembly can be emulated when accu¬ 
rate code is required. Emscripten has built-in 
methods to check for arithmetic overflow, si¬ 
gning issues and rounding errors. If emulation 
is not required, code can be translated without 

20 http://asmjs.org/spec/latest/ 


semantic emulation in order to achieve the best 
execution performance [Zakai, 2011]. 

Implementations of the C and C++ runti¬ 
me libraries have been created for applicati¬ 
ons compiled with Emscripten. These allow pro¬ 
grams written in C/C++ to transparently per¬ 
form common tasks such as using the file sys¬ 
tem, allocating memory and printing to the con¬ 
sole. Emscripten allows a virtual filesystem to 
be created using its FS library, which is used 
by Emscripten’s libc and libcxx for file I/O 21 . 
Files can be added or removed from the virtual 
filesystem using Javascript helper functions. It 
is also possible to directly call C functions from 
Javascript using Emscripten 22 . These functions 
must first be named at compile time so they 
are not optimised out of the resulting compi¬ 
led Javascript code. The required functions are 
then wrapped using Emscripten’s cwrap functi¬ 
on, and assigned to a Javascript function name. 
The cwrap function allows many Javascript va¬ 
riables to be used transparently as arguments to 
C functions, such as passing Javascript strings 
to functions which require the C languages const 
char array type. 

Although Emscripten can successfully compi¬ 
le a large section of C/C++ code there are still 
a number of limitations to this approach due to 
limitations within the Javascript language and 
runtime. As Javascript doesn’t support threa¬ 
ding, Emscripten is unable to compile codeba¬ 
ses that make use of threads. Some concurrency 
is possible using web workers, but they do not 
share state. It is also not possible to directly im¬ 
plement 64-bit integers in Javascript as all num¬ 
bers are represented using 64-bit doubles. This 
results in a risk of rounding errors being intro¬ 
duced to the compiled Javascript when perfor¬ 
ming arithmetic operations with 64-bit integers 
[Zakai, 2011]. 

4.1 CsoundEmscripten 

CsoundEmscripten is an implementation of the 
Csound language in Javascript using the Ems¬ 
cripten compiler. A working example of Csoun¬ 
dEmscripten can be found at http://eddyc. 
github. io/CsoundEmscripten/. The compiled 
Csound library and CsoundObj Javascript class 
can be found at https://github.com/eddyc/ 
CsoundEmscripten/. CsoundEmscripten con- 

21 https://github.com/kripken/emscripten/wiki/ 
Filesystem-API 

““https://github.com/kripken/emscripten/wiki/ 
Interacting-with-code 




sists of three main modules: 

• The Csound library compiled to Javascript 
using Emscripten. 

• A structure and associated functions writ¬ 
ten in C named CsoundObj implemented 
on top of the Csound library that is com¬ 
piled to Javascript using Emscripten. 

• A handwritten Javascript class also named 
CsoundObj that contains the public in¬ 
terface to CsoundEmscripten. The Javas¬ 
cript class both wraps the compiled Cso¬ 
undObj structure and associated functions, 
and connects the Csound library to the 
Web Audio API. 

4.1.1 Wrapping the Csound C API for 
use with Javascript 

In order to simplify the interface between the 
Csound C API and the Javascript class contai¬ 
ning the CsoundEmscripten public interface, a 
structure named CsoundObj and a number of 
functions which use this structure were created. 
The structure contains a reference to the cur¬ 
rent instance of Csound, a reference to Csound’s 
input and output buffer, and Csound’s OdBFS 
value. Some of the functions that use this struc¬ 
ture are: 

• CsoundObj _new() - This function alloca¬ 
tes and returns an instance of the Csound¬ 
Obj structure. It also initialises an instan¬ 
ce of Csound and disables Csound’s default 
handling of sound I/O, allowing Csound’s 
input and output buffers to be used direct¬ 
ly. 

• CsoundObj_compileCSD(self, 
filePath, samplerate, controlrate, 
buffer size) - This function is used 
to compile CSD files, it takes as its 
arguments: a pointer to the CsoundObj 
structure self, the address of a CSD file 
given by filePath , a specified sample rate 
given by samplerate, a specified control 
rate given by controlrate and a buffer 
size given by buffersize. The CSD file at 
the given address is compiled using these 
arguments. 

• CsoundObj_process(self, 
inNumberFrames, inputBuffer, 
outputBuf f er) - This function copies 
audio samples to Csound’s input buffer 
and copies samples from Csound’s output 


buffer. It takes as its arguments: a pointer 
to the CsoundObj structure self, an integer 
inNumberFrames specifying the number 
of samples to be copied, a pointer to a 
buffer containing the input samples named 
inputBuffer and a pointer to a destination 
buffer to copy the output samples named 
outputBuffer. 

Each of the other functions that use the Cso¬ 
undObj structure simply wrap existing functi¬ 
ons present in the Csound C API. The relevant 
functions are: 

• csoundGetKsmps(csound) - This function 
takes as its argument a pointer to an in¬ 
stance of Csound and returns the number 
of specified audio frames per control sam¬ 
ple. 

• csoundGetNchnls (csound) - This functi¬ 
on takes as its argument a pointer to an 
instance of Csound and returns the num¬ 
ber of specified audio output channels. 

• csoundGetNchnlsInput(csound) - This 
function takes as its argument a pointer 
to an instance of Csound and returns the 
number of specified audio input channels. 

• csoundStop (csound) - This function takes 
as its argument a pointer to an instance 
of Csound stops the current performance 
pass. 

• csoundReset (csound) - This function ta¬ 
kes as its argument a pointer to an instance 
of Csound and resets its internal memory 
and state in preparation for a new perfor¬ 
mance. 

• csoundSetControlChannel(csound, 
name, val) - This function takes as its 
arguments: a pointer to an instance of 
Csound, a string given by name, and 
number given by val, it sets the numerical 
value of a Csound control channel specified 
by the string name. 

The CsoundObj structure and associated 
functions are compiled to Javascript using Em¬ 
scripten and added to the compiled Csound Ja¬ 
vascript library. Although this is not necessary, 
keeping the compiled CsoundObj structure and 
functions in the same file as the Csound library 
makes it more convenient when including Cso¬ 
undEmscripten within web pages. 



4.1.2 The CsoundEmscripten 
Javascript interface 

The last component of CsoundEmscripten is the 
CsoundObj Javascript class. This class provi¬ 
des the public interface for interacting with the 
compiled Csound library. As well as allocating 
an instance of Csound this class provides me¬ 
thods for controlling performance and setting 
the values of Csound’s control channels. Addi¬ 
tionally, this class interfaces with the Web Au¬ 
dio API, providing Csound with samples from 
the audio input bus and copying samples from 
Csound to the audio output bus. Audio I/O 
and the Csound process are performed in Javas¬ 
cript using the Web Audio API’s ScriptProces- 
sorNode. This node allows direct access to input 
and output samples in Javascript allowing au¬ 
dio processing and synthesis using the Csound 
library. 

Csound can be used in any webpage by crea¬ 
ting an instance of CsoundObj and calling the 
available public methods in Javascript. The me¬ 
thods available in the CsoundObj class are: 

• compileCSD (f ileName) This method ta¬ 
kes as its argument the address of a CSD 
file fileName and compiles it for perfor¬ 
mance. The CSD file must be present in 
Emscripten’s virtual filesystem. This me¬ 
thod calls the compiled C function Csoun¬ 
dObj _compileCSD. It also creates a Script- 
ProcessorNode instance for Audio I/O. 

• enableAudioInput () This method enables 
audio input to the web browser. When cal¬ 
led, it triggers a permissions dialogue in the 
host web browser requesting permission to 
allow audio input. If permission is gran¬ 
ted, audio input is available for the running 
Csound instance. 

• startAudioCallbackO This method 
connects the ScriptProcessorNode to the 
audio output and, if required, the audio 
input. The ScriptProcessorNodes audio 
processing callback is also started. During 
each callback, if required, audio samples 
from the ScriptProcessorNodes input are 
copied into Csound’s input buffer and any 
new values for Csound’s software channels 
are set. Csound’s csoundPerformKsmps() 
function is called and any output samples 
are copied into the ScriptProcessorNodes 
output buffer. 

• stopAudioCallbackO This method dis¬ 
connects the current running ScriptPro¬ 


cessorNode and stops the audio process 
callback. If required this method also dis¬ 
connects any audio inputs. 

• addControlChannel(name, 
initialValue) This method adds an 
object to a Javascript array that is used 
to update Csound’s named channel values. 
Each object contains a string value given 
by name, a float value given by initialValue 
and additionally a boolean value indicating 
whether the float value has been updated. 

• setControlChannelValue(name, value) 

This method sets a named control channel 
given by the string name to the specified 
number given by the value argument. 

• getControlChannelValue(name) This 
method returns the current value of a 
named control channel given by the string 
name. 

4.1.3 Limitations 

Using CsoundEmscripten, it is possible to add 
Csound’s audio processing and synthesis capa¬ 
bilities to any web browser that supports the 
Web Audio API. Unfortunately this approach 
of bringing Csound to the web comes with a 
number of drawbacks. 

Although Javascript engines are constant¬ 
ly improving in speed and efficiency, running 
Csound entirely in Javascript is a processor in¬ 
tensive task on modern systems. This is especi¬ 
ally troublesome when trying to run even mode¬ 
rately complex CSD files on mobile computing 
devices. 

Another limitation is due to the design of 
the ScriptProcessorNode part of the Web Au¬ 
dio API. Unfortunately, the ScriptProcessorNo¬ 
de runs on the main thread. This can result 
in audio glitching when another process on the 
main thread—such as the UI—causes a delay in 
audio processing. As part of the W3Cs Web Au¬ 
dio Spec review it has been suggested that the 
ScriptProcessorNode be moved off of the main 
thread 23 . There has also been a resolution by 
the Web Audio API developers that they will 
make it possible to use the ScriptProcessorNo¬ 
de with web workers 24 . Hopefully in a future 
version of the Web Audio API the ScriptPro¬ 
cessorNode will be more capable of running the 

2i https://github.com/w3ctag/ 
spec-reviews/blob/master/2013/07/WebAudio. 
md#issue-scriptprocessornode-is-unfit-for-purpose- 

“ 4 https://www.w3.org/Bugs/Public/show_bug.cgi? 
id=17415#c94 



kind complex audio processing and synthesis ca¬ 
pabilities allowed by the Csound library. 

This version of Csound also does not support 
plugins, making some opcodes unavailable. Ad¬ 
ditionally, MIDI I/O is not currently supported. 
This is not due to the technical limitations of 
Emscripten, rather it was not implemented due 
to the current lack of support for the WebMIDI 
standard in Mozilla Firefox 25 and in the Webkit 
library 26 . 

5 Beyond Web Audio: Creating 
Audio Applications with PNaCl 

As an alternative to the development of audio 
applications for web deployment in pure Javas¬ 
cript, it is possible to take advantage of the Na¬ 
tive Clients (NaCl) platform * 2 '. This allows the 
use of C and C++ code to create components 
that are accessible to client-side Javascript, and 
run natively inside the browser. NaCl is descri¬ 
bed as a sandboxing technology, as it provides a 
safe environment for code to be executed, in an 
OS-independent manner [Yee et al., 2009] [Sehr 
et ah, 2010]. This is not completely unlike the 
use of Java with the Java Webstart Technology 
(JAWS), which has been discussed elsewhere in 
relation to Csound [Lazzarini et ah, 2012b]. 

There are two basic toolchains in NaCl: nati- 
ve/gcc and PNaCl [Donovan et ah, 2010]. Whi¬ 
le the former produces architecture-dependent 
code (arm, x86, etc.), the latter is completely 
independent of any existing architecture. NaCl 
is currently only supported by the Chrome and 
Chromium browsers. Since version 31, Chrome 
enables PNaCl by default, allowing applications 
created with that technology to work complete¬ 
ly out-of-the-box. While PNaCl modules can be 
served from anywhere in the open web, native- 
toolchain NaCl applications and extensions can 
only be installed from Google’s Chrome Web 
Store. 

5.1 The Pepper Plugin API 

An integral part of NaCl is the Pepper Plu¬ 
gin API (PPAPI, or just Pepper). It offers va¬ 
rious services, of which interfacing with Javas¬ 
cript and accessing the audio device is particu¬ 
larly relevant to our ends. All of the toolchains 
also include support for parts of the standard 
C library (eg. stdio), and very importantly for 

25 https://bugzilla.mozilla.org/show_bug.cgi? 
id=836897 

2C https://bugs.webkit.org/show_bug.cgi?id= 
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2 'https://developers.google.com/native-client 


Csound, the pthread library. However, absent 
from the PNaCl toolchain are dlopenQ and fri¬ 
ends, which means no dynamic loading is availa¬ 
ble there. 

Javascript client-side code is responsible for 
requesting the loading of a NaCl module. On¬ 
ce the module is loaded, execution is controlled 
through Javascript event listeners and messa¬ 
ge passing. A postMessage() method is used by 
Pepper to allow communication from Javascript 
to PNaCl module, triggering a message handler 
in the C/C++ side. In the opposite direction, a 
message event is issued when C/C++ code calls 
the equivalent PostMessageQ function. 

Audio output is well supported in Pepper 
with a mid-latency callback mechanism (ca. 10- 
11ms, 512 frames at 44.1 or 48 KHz sampling 
rate). Its performance appears to be very uni¬ 
form across the various platforms. The Audio 
API design is very straightforward, although the 
library is a little rigid in terms of parameters. It 
supports only stereo at one of the two sampling 
rates mentioned above). Audio input is not yet 
available in the production release, but support 
can already be seen in the development reposi¬ 
tory. 

The most complex part of NaCl is access to 
the local files. In short, there is no open access 
to the client disk, only to sandboxed filesys¬ 
tems. It is possible to mount a server filesystem 
(through httpfs), a memory filesystem (rnernfs), 
as well as local temporary or permanent file¬ 
systems (html5fs). For those to be useful, they 
can only be mounted and accessed through the 
NaCl module, which means that any copying 
of data from the user disk into these partitions 
has to be mediated by code written in the NaCl 
module. For instance, it is possible to take ad¬ 
vantage of the file HTML5 tag and to get data 
from NaCl into a Javascript blob so that it can 
be saved into the user’s disk. It is also possible 
to copy a file from disk into the sandbox using 
the URLReader service supplied by Pepper. 

5.2 PNaCl 

The PNaCl toolchain compiles code down to 
a portable bitcode executable (called a pexe). 
When this is delivered to the browser, an ahead- 
of-time compiler is used to translate the code in¬ 
to native form. A web application using PNaCl 
will contain three basic components: the pexe 
binary, a manifest file describing it, and a client- 
side script in JS, which loads and allows interac¬ 
tion with the module via the Pepper messaging 



system. 

5.3 Csound for PNaCl 

A fully functional implementation of Csound for 
Portable Native Clients is available from http: 
//vlazzarini .github. io. The package is com¬ 
posed of three elements: the Javascript modu¬ 
le (csound.js), the manifest file (csound.nmf), 
and the pexe binary (csound.pexe). The sour¬ 
ce for the PNaCl component is also available 
from that site (csound.cpp). It depends on the 
Csound and Libsndfile libraries compiled for 
PNaCl and the NaCL sdk. A Makefile for PNaCl 
exists in the Csound 6 sources. 

5.3.1 The Javascript interface 

Users of Csound for PNaCl will only inter¬ 
act with the services offered by the Javascript 
module. Typically an application written in 
HTML5 will require the following elements to 
use it: 

• the csound.js script 

• a reference to the module using a div tag 
with id= “engine” 

• a script containing the code to control 
Csound. 

The script will contain calls to methods in 
csound.js, such as: 

• csound.Play() - starts performance 

• csound.PlayCsd(s) - starts performance 
from a CSD file s, which can be in ./http/ 
(ORIGIN server) or ./local/ (local sand¬ 
box). 

• csound.RenderCsd(s) - renders a CSD file 
s, which can be in ./http/ (ORIGIN server) 
or ./local/ (local sandbox), with no RT au¬ 
dio output. The “finished render” message 
is issued on completion. 

• csound.Pause() - pauses performance 

• csound. CompileOrc(s) - compiles the 
Csound code in the string s 

• csound.ReadScore(s) - reads the score in 
the string s (with preprocessing support) 

• csound.Event (s) - sends in the line events 
contained in the string s (no preprocessing) 

• csound.SetChannel(name, value) 

sends the control channel name the value 
value , both arguments being strings. 


As it starts, the PNaCl module will call a 
moduleDidLoadO function, if it exists. This can 
be defined in the application script. Also the fol¬ 
lowing callbacks are also definable: 

• function handleMessage(message): cal¬ 
led when there are messages from Csound 
(pnacl module). The string message.data 
contains the message. 

• function attachListeners(): this is cal¬ 
led when listeners for different events are 
to be attached. 

In addition to Csound-specific controls, the 
module also includes a number of filesystem fa¬ 
cilities, to allow the manipulation of resources 
in the server and in the sandbox: 

• csound.CopyToLocal(src, dest) - copies 
the file src in the ORIGIN directory to the 
local file dest , which can be accessed at ./lo¬ 
cal/ dest. The “Complete” message is issued 
on completion. 

• csound.CopyUrlToLocal(url,dest) - co¬ 
pies the url url to the local file dest, which 
can be accessed at ./local /dest. Current¬ 
ly only ORIGIN and CORS urls are allo¬ 
wed remotely, but local files can also be 
passed if encoded as urls with the web- 
kitURL.createObjectURLQ javascript me¬ 
thod. The “Complete” message is issued on 
completion. 

• csound.RequestFileFromLocal(src) 

requests the data from the local file src. 
The “Complete” message is issued on 
completion. 

• csound. GetFileDataO - returns the most 
recently requested file data as an ArrayOb- 
ject. 

A series of examples demonstrating this API 
is provided in github. In particular, an introduc¬ 
tory example is found on http: //vlazzarini. 
github.io/minimal.html. 

5.3.2 Limitations 

The following limitations apply to the current 
release of Csound for PNaCl: 

• no realtime audio input (not supported yet 
in Pepper/NaCl) 

• no MIDI in the NaCl module. However, it 
might be possible to implement MIDI in 



JavaScript (through WebMIDI), and using 
the csound.js functions, send control da¬ 
ta to Csound, and respond to the various 
channel messages. 

• no plugins, as pNaCl does not support 
dlopenQ and friends. This means some 
Csound opcodes are not available as they 
reside in plugin libraries. It might be possi¬ 
ble to add some of these opcodes statically 
to the Csound pNaCl library in the future. 

6 Conclusions 

In this paper we reviewed the current state of 
support for the development of web-based au¬ 
dio and music applications. As part of this, we 
explored two approaches in deploying Csound 
as an engine for general-purpose media softwa¬ 
re. The first consisted of a Javascript version 
created with the help of the Emscripten com¬ 
piler, and the second a native C/C++ port for 
the Native Client platform, using the Portable 
Native Client toolchain. The first has the advan¬ 
tage of enjoying widespread support by a varie¬ 
ty of browsers, but is not yet fully deployable. 
On the other hand, the second approach, whi¬ 
le at the moment only running on Chrome and 
Chromium browsers, is a robust and ready-for- 
production version of Csound. 
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